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1. Overview 


To help ensure the quality of Windows Phone engineering devices entering into 
Windows Phone test labs at both the Microsoft Redmond location and at OEM offsite 
facility labs (OFLabs) across the globe, the OSG Hardware Automation Team has 
established a set of guidelines, requirements and policies that OEMs and 
BSP/Device platform teams must comply with before bringing a new device 
platform into the Windows Phone test automation labs. This process is also known 
as “Onboarding”. 


This program guide provides the guidance and details on the requirements that a 
new device platform has to meet before the platform can be certified as 
“Accepted” for use in the Windows Phone test automation labs. 


There are checklists at the end of this document that are required to be filled out to 
onboard devices for the OFLabs. 


1.1. How to use this document 


This document is primarily divided into three sections: 


Section 1: Details the general information common to onboarding new devices 
into both Microsoft, Redmond test labs and OEM OFLabs across the globe. 


Section 2: This section provides the details of the program specific to and 
applicable only to onboarding new device platforms into Microsoft’s Windows 
Phone test labs in Redmond. 


Section 3: This section provides the additional details of the program applicable 
only to onboarding new device platforms into Windows Phone Test labs at OEM 
offsite facility locations (OFLABS) that are serviced by the WPQS team globally. 


Once section-1 is reviewed you can skip to either section-2 or section-3 directly 
based on which labs you are interested in onboarding a new device/platform 
into. 


1.2. Summary of changes since 1.5 


e Added crash dump configuration information 
e Updated Chassis specification version 

e Added Crashdump settings section 

e Added Acronyms / Definitions section 

e Added Battery Blank information to appendix 
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1.3. Scope 


This document only details the requirements for lab entry of Windows Phone 
engineering devices that are designed to work with Windows Phone Apollo or 
later OS releases. 


Please note that this document may be updated for future projects and will be 
published with changes when available. Please contact OSGHAT for any 
questions related to this document. 


1.4. Contacts for Questions 


For specific questions related to this document or the device onboarding 
process for Windows Phone Redmond labs, contact OSGHAT. For specific 
questions related to device onboarding at Windows Phone offsite labs at OEM 
locations contact WPQS team. 


1.5. Test Services 


The OSG Harware Automation Team team (OSGHAT) only acts as a quality 
certification authority for the onboarding of new device platforms into Windows 
Phone Test automation labs. The goal of the OSGHAT team is to help facilitate 
easy transition of new device platforms that meet established engineering and 
quality requirements into Windows Phone test labs. Also, the OSGHAT Team 
provides only a high level validation of the lab requirements, verification of 
scalability and reliability metrics for the new BSP platform to be able to certify 
that the platform either does or does not meet the Windows Phone test lab entry 
requirements. 


It is expected that OEM, BSP/Device Platform development teams perform 
thorough validation and readiness testing of the platform with respect to the lab 
entry criteria explained in this document prior to submitting the platform for 
Microsoft Windows Phone Test lab entry. 


Once the platform is certified as meeting the Windows Phone Test lab’s entry 
criteria, respective test execution and triage teams will formally start supporting 
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test services for the platform either in Redmond labs or at Offsite labs based on 
the case. 


You can contact one of the Test Execution and Triage Services teams listed 
below based on your case: 


For OEM Offsite Labs (OFLABS): Contact WPQS team. 
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2.Windows Phone Test Lab 
Entry Requirements 


2.1. Common Requirements 


This section details the requirements applicable to both OSG Test Labs at 


Redmond and OSG Offsite Test labs (OFLABS) at OEM facilities. 


2.1.1. Battery related 


Historically during previous Windows Phone projects like Mango and Apollo, it 
was proven time and time again that properly designed battery blanks are a 
crucial part of the lab onboarding process and could quickly become progress 
blockers for both lab entry and lab onboarding of the devices if not built with 
care or built early enough in the product cycle. Engaging OSG Hardware 
Automation Team (OSGHAT) early in the process of preparing a new device 
platform, especially with regard to battery blanks for engineering phones 
proved quite helpful in speeding up the overall lab onboarding process for the 
new platforms to prevent any issues and avoid any unnecessary delays later 
during the device onboarding process. 


OSGHAT team would be happy to support and assist OEM, BSP/Device 
platform development teams in resolving issues related to design, validation 
and entry certification of the proposed battery blanks. 


Additional information is included in the Appendix Battery Blank Guide 


2.1.1.1. Battery Blanks 


Phones must include a battery blanks that meets the requirements listed 
in the Windows Phone Apollo Performance Chassis specification. This 
includes the requirement that the battery blank must fit in the device’s 
battery compartment completely flush with the back of the phone, which 
is necessary to fit the phones in the test lab trays for automated testing. 


For more information, see Item 2.4.3-1 in the Performance Chassis 
Verification Checklist. Note that this particular description of battery 
blank design does not specifically address phones with a non-removable 
back. However, the same requirements apply. 
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The following figure shows the specific wiring requirements for the battery 
blank (as specified in Figure 4: Battery Blank Test Rig in the Apollo 
Performance Chassis Requirements Specification). 


Connector Pins~=~~___ 
Molex PN 39-00-0047. ~~ 
Digikey PN WM2503-ND ~~~ 


20 AWG, 5" long wire 


Battery Blank 


Connector Shell 
Molex PN 39-01-2020 
Digikey PN WM3700-ND 


Fig. 1: Battery Blank Test Rig 


2.1.1.2. Battery Cover 


Phones with removable back covers: The phone must work with the 
back cover removed to accomplish the required wiring. In any case, the 
device should NOT require the battery cover to be physically installed to 
power on the device. Please note that, Battery bypass modifications 
generally require the routing of wires from the battery to an external 
power source and therefore prevent the installation of the battery cover. 


Phones without removable back covers / Uni-body construction: 
The phones provided must include the appropriate modification needed 
for utilization of an external power source, i.e€., an opening must be cut in 
the back of the phone and leads must be pre-installed in the device 
allowing connection to an external power source. 


Overall Thickness: In both cases, any modification made to the phone 
must not increase the thickness of the phone by more than 0.1” (2.54 
mm). 


2.1.2. Hardware Requirements 


The Windows Phone Chassis Requirements Specification and associated 
addenda are the authoritative source for Windows Phone hardware 
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requirements and all engineering phones must meet those requirements 
before being submitted for the Lab Quality Certification Program. The 
guidelines and requirements listed here are either already included in, or in 
addition to the Chassis specification and do not replace or substitute them in 
any way. 


2.1.2.1. Micro USB Port: 


Devices must support a high speed Micro-USB 2.0 port per Chassis 
Specification. 


2.1.2.2. Free Space: 


The phone should have at least 3 gigabytes (GB) of free space on the 
phone - (or on an SD card in the phone). Automation testing typically 
needs this space to copy needed tools and test binaries to the phone as 
well as required data for tests. 


2.1.2.3. Device Power-on behavior: 


Phones must be able to automatically power cycle in the test trays; i.e., 
without needing to use a physical button press on the phone. The specific 
behavior should be: 


e The phone must power on when you apply voltage to the battery and 
connect it to the USB port. 

e The phone must power off when it is disconnected from the USB and 
battery. That is, when you disconnect for several seconds, the phone 
must power off. 


2.1.2.4. External power source wiring: 


The phone must provide a way to be able to bypass the battery for 
automated testing. Routing wires must be added that can run from the 
battery to an external power source. The wire going to the positive (+) 
pin must be “red” and the wire going to the negative (-) pin must be 
“black” in color as per standard electrical practices. 


For specific wiring requirements, see Fig. 1. Hardware based recovery: 


In cases where a device is “bricked” by a bad image or driver code, it 
must be able to be recovered through a process using a JTAG connector or 
an equivalent setup using that may require manual steps (e.g. bringing 
the device into mass storage mode by pressing and holding the volume 
key up/down which would enable the device to be re-flashed). 
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2.1.3. Software Requirements 
2.1.3.1. Soft Reboot 


The phone must pass the System Shutdown and Reboot API Test which 
uses InitiateSystemShutdownEx API. This is required to do a soft reboot 
on the phone. 


2.1.3.2. Warm Reboot 


The device platform must support rebooting from the OS without entering 
into download mode (i.e., “Warm” Reboot). 


2.1.3.3. USB behavior must be stable 


The BSP for the device platform should meet general USB stability 
metrics. Usually this requirement is validated based on the results 
gathered from the platform reliability stress test (aka. the “100X Reset 
Stress Test” pass). 


2.1.3.4. Device communicates via KDNet 
over USB protocol 


The platform’s BSP must be compatible with the KDNet over USB 
communication protocol. Specifically, the device should be able to 
establish a connection and communicate via the KDNet over USB protocol 
when connected to the host PC via a USB channel. 


2.1.3.5. Devices supports unique identifier 


Each device supports and exposes a un/que device identifier that must be 
persistent all through the life cycle of a device. This unique identifier is 
very important to get the devices working in a lab automation 
environment. 


Note: WTT/Texus automation systems do not support device ID collisions 
in their device repository (MR) logic and cannot effectively schedule tests 
on devices with duplicate identifiers. This requirement is critically 
important! 


2.1.3.6. Device Platform must meet 
Robustness Requirements 
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2.1.3.6.1. Devices must be able to boot into the main OS with 
or without an invalid or an in-active SIM installed in 
them. 

2.1.3.6.2. Programmatically set UEFl and other boot manager 
settings must persist across multiple power cycles of the 
devices. 

2.1.3.6.3. Devices must not be bricked or become 
irrecoverable if downloading and (or) flashing a 
corrupted/bad image and or if the UEFI/OS download fails. 

2.1.3.6.4. If a device gets bricked it must be recoverable using 
a flashing utility such as QPST (or an equivalent utility), or 
via the supported method of recovery using a JTAG 
connector, etc. 

2.1.3.6.5. Devices support programmatic recovery of the 
devices from a _ bad/corrupted flash via Emergency 
Download Mode or an equivalent method. 

2.1.3.6.6. The device prevents or fails to flash when an 
incorrect/invalid image is being flashed onto the device 
through automation. 


2.1.3.7. Device Platform must meet 


Reliability Requirements 

2.1.3.7.1. The platform’s FRE Images (built with flags and tools 
to support automation testing) must meet an average 
pass rate of 99% or better in a typical Power Cycle- 
>Download->Flash->Boot reliability stress test, also 
known as “100X Reset Stress Test.” 

2.1.3.7.2. The platform CHK Images (built with flags and tools 
to support automation testing) must meet an average 
pass rate of 99% or better in a typical Power Cycle- 
>Download->Flash->Boot reliability stress test, also 
known as “100X Reset Stress Test.” 

2.1.3.7.3. The above tests must be run in a configuration of at 
least 12 devices connected to single supported host 
configuration (i.e., 1:12) on the platform’s automation 
image available from official POD release servers. 
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2.1.3.7.4. Device side _ flashing/transport components’ can 
support flashing of 12 devices concurrently on a single 
host (in Pioneer/ Voyager tray scenarios). 

2.1.3.7.5. Devices maintain a reliable and long-term connection 
via KDNet over USB protocol with no loss of connection for 
at a least 24 hour period. This test must be run only on 
devices powered via approved battery blanks. 

2.1.3.7.6. Devices with an installed OS image loaded with 
debug symbols maintain a reliable and long-term 
connection via KDNet over USB protocol with no loss of 
connection for at least a 24 hour period. This test must be 
run only on devices powered via approved battery blanks. 


2.1.3.8. Device Platform must meet Debug- 
ability Requirements 


The platform must meet the below debug-ability requirements to facilitate 
easy diagnose-ability and troubleshooting of device side issues when they 
run automation testing. 


2.1.3.8.1. Device must expose/present the correct BSP version 
of the device via Registry or User Interface or through a 
standard device info package for debugging and 
troubleshooting BSP issues. 


2.1.3.9. Device must expose necessary 
information for infrastructure tools 


Device must expose necessary information/device side flags to enable 
infrastructure tools such as the WTT Device Detection tool to identify and 
register the device with the test infrastructure. 


2.1.3.10. Device Platform must meet 
Performance Requirements 


The Flashing behavior of the device/platform must meet or exceed the 
requirements outlined in section 2.2.2 “Flash type and _ layout 
requirements” and meet or exceed the rates listed in section 2.2.5 “Flash 
memory performance” in the “Chassis Requirements Specification”. 
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2.1.3.10.1. The time it takes to power on and enumerate the 
device as a simple IO device must be no more than 
established KPlis (e.g.. 5 sec KPI + 3 sec for USB bus 
enumeration overhead on a PC) for a single device 
connected to a host directly via USB 

2.1.3.10.2. It must be possible to document the time taken to 
perform pure flashing (FFU App execution time) for 
analysis purposes. 

2.1.3.10.3. The throughput of pure flashing (FFU App execution 
time) performance must be better than or equivalent to 
the established KP! number (4MB/s) in a desktop scenario. 

2.1.3.10.4. The throughput of pure flashing (FFU App execution 
time) performance must be with-in the 40% tolerance 
range of flashing throughput KPI in Automation trays. 

2.1.3.10.5. The time it takes to boot to the main OS should meet 
the KPI (15 sec). 
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2.1.4. Device Health lab quality 
requirements 


2.1.4.1. Device must display its own phone 
number 

Devices when installed with active SIMs must display their own phone 

number in the Settings-> Application Tab-> Phone screen under 

“Phone Number” in the Phone UI. 

2.1.4.2. Device must pass boot reliability 
stress test with >=99% pass rate 

The platform must achieve an average pass rate of 99% or more in 

a typical Reset-> Download->Flash->Boot reliability stress test 

(aka. the “100X Reset Stress Test”). This test must be run in 

configuration of at least 12 devices connected to a single 


supported host configuration on the platform’s image for Device 
Health testing. 


2.1.4.3. Device must pass Idle Power Test 
with >=99% pass rate 


A device can be shut down completely and power draw goes 
below 1mA for at least 5 seconds after shutdown. 


2.1.4.4. Device must pass Minconsole Test 
with >=99% pass rate 


A device can be shut down completely and power draw goes below 
1mA for at least 5 seconds after shutdown. 
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2.1.5. General Requirements 


2.1.5.1. Device preparation/setup & flashing 
instructions document 


The Platform/BSP team must be provide documented instructions for first 
time preparation and setup for flashing the images onto the devices. 


2.1.5.2. BITS Test Run 


The device platform must pass a BITS test run at least one time with a > 
99% pass rate or equivalent to or better than the pass rates of a bench 
mark platform with no known device/platform side issues before a sign-off 
can be provided by OSGHAT for Windows Phone Test lab entry. 


2.1.5.3. Debug accessories made available 


We recommend that the Device/Platform teams ensure the availability of 
at least 10-20 JTAG/Serial debug enabled devices, including any required 
accessories available, for use in case of investigations well before lab 
deployments are complete. 


2.1.5.4. Device Platform must have no active 
sign-off blocking bugs 


There must be no active Pri-O or Pri-1 active code bugs that could 
potentially block sign-off for Windows Phone test lab entry. 


All blocking code bugs opened during onboarding testing must be 
resolved, verified and closed before OSGHAT can provide an official sign- 
off and approval for the platform so as to facilitate large scale lab 
deployments and production test runs. 
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2.2. Redmond Labs specific additional 
requirements 


This section outlines the requirements specifically applicable to Windows Phone 
Redmond Labs, only. 


2.2.1. Build availability from PODS 


Before a device platform is submitted for the lab certification process in 
Redmond Labs it is expected that the device platform team ensures the 
below images for lab automation testing for the platform are available from 
the official POD release servers. 


e FRE TEST Images: These images are built with flags and packages 
needed to support automation testing and are of the FRE version. 

¢ FRE CHK Images: These images are built with flags and packages 
needed to support automation testing and are of the FRE version. 

e¢ FRE HEALTH Images: These images are built with flags and packages 
needed to support Device Health and MTBF testing and are of the FRE 
version. 
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3. Offsite Labs (OFLABS) specific 
additional information and 
requirements 


This portion of the document explains the preparation process the OEM teams 
must perform before testing can begin on a device in the Windows Phone CXE 
OFLabs (Offsite Facility labs) and any additional device onboarding requirements 
or guidelines specific to Offsite labs in addition to the ones explained in 2.1. 
above. 


The Windows Phone Quality Service facilitates running these tests and is a 
program in which Microsoft’s WPQS Team enables testing of OEM Windows 
Phone devices using a Microsoft hardware and infrastructure made available at 
OEM premises. 


3.1.1. Test Content once onboarding is 
complete 


Once onboarding of a device is complete, we have over 20,000 tests available as 
part of a gradual bring up process. We prioritize the test pass in the following 
areas to enable teams to focus on particular areas first. The top 20 test pass 
areas are shown below 


e Kernel BVT - Basic Verification Test 
e File System BVT - Basic Verification Test 
e Reboot 100x 
o Reboot stress test 100x 
e Reboot 400x 
o Reboot stress test 400 


e RESET 
o Reset your devices (settings, about, reset) 
e MTBF 
o Mean Time Between Failure 4hr GSM 
e Stress * 
o UI Stress application cycle tests 
e VCS 


o Voice Call Stability 
e BSP Integration 
o BSP Integration test pass has hundreds of tests covering 
sensors, media streaming, graphics and kernel 
e Kernel 
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o Tests from the Kernel and File System team that cover from 
flash performance to kernel settings 
e Drivers 
o Drivers and Sensors test pass covering all sensors 
e Graphics (including Rendering) 
o Basic graphics tests for D2D and D3D 
o D3D9 tests ported from the Desktop Windows team 
o D3D tests maintained by the Windows Phone team for D3D tests 
o D3D 10level9 and D3D11 tests ported from the Desktop 
Windows team 
o D2D tests maintained by the Windows Phone team 
o Display brightness API tests 
o Rendering API and core UI functional tests including rotation 
e  VideoCodecs and AudioCodec 
o AudioCodec related tests covering such areas as AAC, MP3 and 
AMR 
o Video codec test suite covering such codecs as Mpeg4pt2, VC1, 
H263, H264 
e DeviceUpdate 
o Device update tests to verify settings and updates 
e BITS 
o Branch Integration Test Suite covers basic tests across most 
areas of the product 
e BITs_LiveSim 
o Tests that require a LiveSIM and is run in the USA 
e Camera 
o Camera tests covering front, rear and capture tests 
e BrowserUX 
o Basic Browser tests like opening the Browser and rendering 
pages 
e Browser Stress 
o A 30 hour Browser site crawler test 
e Location 
o Tests for Location / AGPS / GNSS drivers 
e Networking 
o Test Suite Covering Winsock Breadth testcases 
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Important: 


In the partner documentation and in this document, "Chassis Requirements 
Specification" refers to the appropriate Chassis document for your release. 


e Windows Phone “Blue” Chassis Requirements Specification (v1.2 January 
24, 2014) 


Those documents are the authoritative source for Windows Phone hardware 
requirements and it is expected that OEM devices must meet those 
requirements. 


3.1.2. Additional guidelines and 
information 


The following additional information has been provided to help ensure OEMs 
understand with the requirements outlined in this document. Please contact 
the WPQS team incase you have any questions or need additional information 
on any of the topics presented in this document. 


3.1.2.1. Crash Dump settings 
It is important to set the crash dump setting for OFLab runs so 
that crash dumps can be captured and help you address issues 
prior to release. See the table below for details on what to set. 


Kernel Crash Registry Values 
Key: HKEY_LOCAL_MACHINE\System\ControlSet001\Control\CrashControl 


Name Type Default Comment 


AutoReboot dword Oxl Boolean that enables or 
disables automatic reboot 
after a system crash (blue 
screen). 


CrashDumpEnabled dword 0x3 Controls the dump type to 
be taken in the case of an 
unhandled fault in the 
kernel process. 
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DedicatedDumpFile 


DumpFileSize 


AlwaysKeepMemoryD 
ump 


3.1.2.2. 


c:\Data\ 


expand_ /SystemData\ 


SZ 


dword 


dword 


DedicatedDump. 
Sys 


Ox1 


0x0 


O - Disabled 


2 - Kernel memory dump 
(only dumps pages 
mapped into the kernel 
process address space, 
does not include user 
processes) 

3 - Minidump (stack and 
registers) 


Path of the dedicated 
dump file (This is 
effectively a system- 
allocated page file used for 
writing the dump. After the 
dump is written into the 
dedicated dump file, it is 
then extracted out of it 
into the same directory.) 


Size of dedicated dump file 
in MB 


Boolean indicating whether 
to leave the crash dump 

on the device and 
DumpFile registry key after 
processing the dump 


Unified Extensible Firmware Interface 


(UEFI): 


Windows Phone utilizes the Unified Extensible Firmware Interface (UEFI) to 
support the handoff of system control from the SoC firmware bootloader 
to the Windows Phone OS. The UEFI environment is a minimal boot OS 
upon which Windows Phones are booted and the OS runs. For more 
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information, please refer to UEFI section of the Windows Phone "Blue" 
partner documentation. 


3.1.2.3. The Windows Phone Boot Manager 


The Windows Phone Boot Manager is a Microsoft-provided UEFI application 
that sets up the boot environment. Inside the boot environment, individual 
boot applications started by the Boot Manager provide functionality for all 
customer-facing scenarios before the phone boots. 


Boot applications implement functionality for the following scenarios: 
e Charging the phone battery before boot. 
e Capturing and saving offline crash dumps (developer builds only). 
e Flashing the phone with a new image. 
e Resetting the phone. 
e Updating the phone. 
¢ Booting the phone to the main OS. 


For OFLab images we need to have the charging turned off in the UEFI as 
the devices will have battery blanks - see section below “No Charging files 
for Battery Blank lab builds” for more details on how to verify this. 


For more information, please refer to the “Boot Overview” section of the 
Windows Phone “Apollo” partner documentation. 


3.1.2.4. Device info implementation 


The phone must have appropriate values set for Device Targeting. OEMs 
may need to edit the $(HKLM.SYSTEM)\Platform\DeviceTargetingInfo 
registry key in the DeviceTargetingInfo.pkg.xml file to support this 
functionality. 


3.1.2.5. Supported Applications Processors: 


The device must use one of the supported applications processors as 
listed in Table 2 in Section 2.1 in the “Chassis Requirements 
Documentation” 


3.1.2.6. BSP release version: 


The phone image must support the most recent Board Support Package 
(BSP) that runs with the most recent Windows Phone “Apollo” Adaptation 
Kit (AK) release. Additional details can be found in the “Pairing Note” 
section of the Windows Phone release notes. 
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3.1.2.7. Test Central Tests 


The phone should pass the Test Central BSP tests that verify these 
software guidelines. As a general guideline the level of readiness should 
be that the phone boots up into the appropriate boot loaders, UEFI tests 
pass and KDnet Debugging is possible. As is normal, process Kernel, 
memory & file system tests are good tests to run. 


3.1.2.8. Build Settings 


There are three main types of builds that are used in the OFLabs testing, 
they are: Test, Health/MTBF and Production. Some tests only run on 
certain images. All builds require specific settings and or flags to support 
automation tests. Additional details can be found in the “How to: Build a 
phone image” section of the Windows Phone Partner Documentation. The 
below table provides some details of what to include in the OEMInput.XML 
file while creating an image for testing in OFLABS. Sample files are 
provided in the SKUfile 


InternalOptionalFeatures Relea | Type of tests 
se 
Type 
Test —IMGFAKEMODEM Test Most tests run on 
image DISABLEUSERMODECI this image 
Ise DISABLEKERNELMODECI including drivers; 
TestOEMI BITS (Branch 
nput.xml) ENABLETESTSIGNING Integration Test 
CODEINTEGRITY_TEST Suite). It is 
ENABLE_FFU_PLAT_ID_CHE recommended to 
CK test with a real 
LOCATIONFRAMEWORKAPP modem therefore 
DEBUGGERON younsed:to 
remove 
TESTINFRASTRUCTURE IMGFAKEMODEM 
MSINTERNALTESTS and add LABIMAGE 
MSTESTS to the default 
D3DSDKFILES sample file 


STARTUPOVERRIDES 


SECURITYMODELTESTSUPP 
ORT 
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GWPCERTTESTPROV 
NOTMULE 
MOBILECORE_TEST 
BOOTSEQUENCE TEST 


CODEINTEGRITY_PROD 


ENABLE_FFU_PLAT_ID CHE 
cK 


PRODUCTION_CORE 


PSEUDOLOCALES 
LABIMAGE 
Health DISABLEUSERMODECI Test Device health, 
and DISABLEKERNELMODECI device stress and 
eee ENABLETESTSIGNING ee 
this image. 
CODEINTEGRITY_ TEST . 
~ Note: Settings 
ENABLE_FFU_PLAT_ID_CHE fronthecample 
ck file Deviceinfo.xml 
DEBUGGERON registry must be 
STARTUPOVERRIDES present for Device 
SECURITYMODELTESTSUPP Health to report 
ORT results correctly. 
MOBILECOREBOOTSH 
CORECLRTESTHOST 
HEALTH 
PRODUCTION_CORE 
BOOTSEQUENCE TEST 
KDNET 
LABIMAGE 
Productio ENABLETESTSIGNING Test The Production or 


Retail builds are 
currently not used 
in the OFLabs but 
may be used in the 
future. Note the 
“Retail” 
OEMinput.xml 
sample doesn’t 
allow the use of 
test applications 
on it as denoted by 
the ReleaseType. 


For any build, before they get to the OFLAB, OEM teams must: 
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e Read the Microsoft Release Notes for the build in case any instructions 
change. 


e Verify that you are using the same optional features as included in the 
sample OEMInput.XML files to include the correct settings for the builds 
(in particular the healthOEMInput.xml) and make sure Optional Feature 
“LABIMAGE” is included in the test builds. 


e Make sure Device Targeting settings are included in the image, 
especially PhoneSoCVersion & PhoneModelName, 
PhoneManufacturerModelName 


o If these values are being changed from build to build, let the 
WPQS team know so they can make changes in WPQS test 
systems for Test Reporting to work. Ideally these shouldn’t 
change from build to build as the trending information on health 
reports can be lost otherwise. 


3.1.2.9. Steps to run tests outside of the lab 
before onboarding an image. 


1. Take the device image that was last run in the OFLAB and flash that 
image ona device using ffutool, or 


2. Take the new image that you want to onboard into the Lab and 
flash using ffutool 


a. ffutool -list to show the device 
b. ffutool -flash <local path to image> 
c. If image flashes then you have followed the same test as 
flashing in the lab 
i. NOTE: If you have to use the ffutool -force setting for 
this to work then it will fail in the lab and this means 
you need to do manual flashing of lab devices. 


d. If the image fails it will give an explanation of what the 
mismatch is and will show the details - pass that back to 
R&D to get a new image that’s designed for the phone. 


3. Perform basic testing on that image - outside of the lab you can use 
Test Central 


a. File System BVT - This can be found in Test Central please 
Suite2_ CoreSystem -> File system -> File System BVT 


Copyright Microsoft 2014 - version 1.9 may be subject to change. 
Last updated: July 7, 2014 
26 
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i. This test checks that a basic test can be run on the 
image 


Untitled - Windows Phone 8 Test Central 


File Connection Test Help 
‘iad &\> a 


Test Definition: Workflow 


4 


We Ueri 


\@) Validation of Volume Up and Volume Down in UEFI 
\@) Validation that the Phone Comply with the JTAG requirements 


L.§ Cellular 


Lab Application Processor 


nm) Suite2_CoreSystem 


Display 


Sensors 


Multimedia 


Input 


UEFI 


Battery 


Cellular 


feEEEEEEE 


File System 


._ mom on 


Lb) Check partition size and free space 

Lb) File System BVT 

») File System FolderPath API test - run in AppContainer Chamber - SD not Present 
Lb) FilelO API Stress Test 

Lb) Storage Usage Test 


4 


b. System Shutdown and Reboot API Test - This is in 
Suite3 Application 


This test checks that the phone actually reboots ok 


For the reboot tests in particular, on the health images 
and on the RIO devices, we’ve seen a lot of devices fail 
this test even if it’s run a couple of times. So passing on a 
single device doesn’t rule out individual device quality 
issues but it’s a really basic test. 


This test is accessible in Test Central Suite3_Application 
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(he Untitled - Windows Phone 8 Test Central 
File Connection Test Help 
iia al| @ h&\> =a 
Test Definition: Workflow C 
LD Kernel . 
Networking 
Debugger 
Policy 
Backlight 
Windows Phone Update 
GPS 
Notification 
Communications 
Connectivity 
Storage 
Driver Verifier 
Ld usB 
2 Py Suite3_Application 
I Sensors 
I lab User Interface 
LQ Display 
|.) Multimedia 
I lad Cellular 
4) & Kernel 
a -] System Shutdown and Reboot API Test 


lab End User Scenarios 


EEEEEEEEEEEE 


I 
I |.) Communications 
I L.) Platform 

I Lab Browser 
I 

I 

I 

I 


LQ) Syne 

} Settings 

lub Hubs 

Lad Input | C:\Program 


3.1.2.10. No Charging files for Battery Blank lab 
builds 


Having these files switches off charging in the devices when using battery 
blanks in the lab. If you need to do this to a lot of devices, please contact 
the OFLabs team for assistance. 


a. Connect the device in Mass Storage mode. 
b. Open up my computer and identify the drive letter for the DPP partition 
of the phone. 
c. Open the DPP partition and go to the following folder: <driveletter>:\ 
DPP\Microsoft 
d. Check to see if the files needed are present: 
i. PVK: Will see a file called: 
1. Microsoft.pvk 
ii. DisableBatteryChargingFixes: Will see two files - these files 
should be empty but their name is important, create these if not 
present. 
1. BatteryFixedPercent.txt 
2. USBNoCurrentDraw.txt 


3.1.2.11. Device Dimensions 
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Please fill in the table at the end of this document for all new devices 
being onboarded to ensure settings are done correctly. It is recommended 
to start testing with USA English language devices. 


3.1.2.12. USBView 


USBView (Universal Serial Bus Viewer, Usbview.exe) is a Windows 
graphical user interface application that enables you to browse all USB 
controllers and connected USB devices on your computer. USBView works 
on all versions of Windows. It is included in the Debugging Tools for 
Windows package to assist in the discovery of USB ports when initiating a 
USB debugging session. 


3.1.2.13. OFLab Portal site 


The oflab portal site https://wpqs.sfone.net is where you'll be able see 
your test results onces the device is onboarded and test runs have 
completed. 
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4. Acronyms 


To help you as your teams have worked through this document we’ve provided a 
couple of checklists here for completion to make it more efficient when onboarding 
devices into the OFLabs 


4.1. Terms used by the Windows Phone 
Division 


Term Definition 


100X Reset A stress test that performs a Reset-> Download->Flash->Boot 
Stress Test cycle that must maintain 99% reliability 


Adaptation Kit 
“What we ship to OEMs” 
Battery A pseudo battery used to connect a phone into the test lab trays 
Blank see Battery Blanks 
BITS Branch Integration Test Suite 
BSP Board Support Package 
“Drivers + HAL” 
BVT Basic Validation Test(s) 
CHK image | Check build, where extra checks and asserts are compiled into the 
binaries 
Cl (as used in DISABLE USER MODE Cl) 
Device 
Onboardin 
g 
FFU 
“image to flash on a phone” 
FRE image | Free build, where binaries are compiled with optimizations for release 
GA General Availability 
“Customers can buy a phone” 
GWP (as used in GWP CERT TEST PROV) 
KDNet 
KPI 
Full Test Pass 
MOs Mobile Operator 
AT&T, Verizon, Sprint,.. 
MTBF Mean Time Between Failures 
#1 AT&T “acceptance test” 
OF Offsite Facility 
OFLabs Offsite Facility Labs 
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Term Definition 
Test lab at an OEM site working in conjunction with Microsoft Device 
Test 

POD 

PVK 

SHA Self Host Acceptance test 
criteria before the build used by Microsoft folks internally 

TA Technical Acceptance 
“MO allows a phone on the network” 

WPHRD Windows Phone Test Hardware Engineering team 
mailto:wphrd@microsoft.com 

WPQS Windows Phone 

team The Test Execution and Triage Services team for Offsite Labs 
mailto:wpqs@microsoft.com 

WTT Windows Test Technology 


4.2. Terms used throughout the Phone 
Industry 


Definition 
"BGPP | Third Generation Partnership Project 
"A-GNSS | Assisted Global Navigation Satellite System 
fats TOSOCSOSOSOSOCOCSCSC‘(#NNCW 
"API__| Application program interface 
"ARM | Advanced RISC Machines 
'BSP___| Boardsupportpackage SSS 
“CDMA | Code Division Multiple Access 
DDI Display driverinterface 
DH (Devicehost SSS 
‘DPP | Device provisioning partition 
"eMMC | Embedded MultiMediaCard 
‘FFA | Form-factoraccurate 
‘FM | Frequency modulation 
“GDI Graphics-device interface 
“GPRS |General Packet Radio System 
“GPS | Global Positioning System 
"GSM Global System for mobile communication 
W264 (| iU-Tstandard SCS 
HCL [Host controllerinterface 
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Definition 


HDQ or I2C fuel gauge communications 


a a 
‘ISP| Image signal processor SSSOS~S~S 
WTO [indiumtinoxide SSOS—~—S 
INCD [Just Noticeable Color Difference 


JTAG Joint Test Action Group 
The IEEE 1149.1 Standard Test Access Port and Boundary-Scan 
Architecture 


ITO 
“Mbps | Mega (1,000.00) bits persecond SS 
"MBps | Mega (1,000,000) bytes persecond 
(NFC_[NearField Communication SSS 
"OEM | Original equipment manufacturer 
(OMA | OpenMobile Aliance SSS 
"RAM [Random access memory SSS 
(RDS _|[RadioData System SSS 
‘SD |SecureDigitalcard —SSCS~—~—~S 
‘SDK | Software developmentkit SSS 
‘SE _—|Secureelement SS SOS—~SCS 
‘SIMD | Single Instruction, MultipleData 
"LDR | SoftwareloaderSOS—~—~—~S 
‘SOC | Systemonachip SOS—~—~—SS 
‘SWP_|Singlewire protocol SSOS—~—~—~S 
UEFI | Unified Extensible Firmware interface 
Ul [UserinterfaceSSOSC—~—SSSCS 
USB |[Universalserialbus SSS 
WAPI__| WLAN Authentication and Privacy Infrastructure 
W-CDMA | Wideband Code Division Multiple Access 
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5. Checklists 


To help your teams work through this document, we’ve provided a couple of 
checklists here to make it more efficient when onboarding devices into the OFLabs. 


Device Onboarding Checklist 


Confirm that the device meets the Chassis specification 
Confirm that the device operates within the proper voltage range (3.9 - 4.2 


volts) 


Confirm that the device is properly reporting it's unique identifier (This will 
be hashed to become the device name in WTT) 


Confirm that the device exposes its own phone number (Needed for 
Device Health/MTBF) 


Confirm that the "device targeting" values are properly set (Registry Key: 
$(HKLM.SYSTEM)\Platform\DeviceTargetingInfo) 


Confirm that OEMInput.XML is configured correctly 


Confirm that PVKs are installed on the device (Needed for MTBF / Device 
Health / Marketplace & Windows Live tests) 


Confirm that the device dimensions sheet has been properly filled out 
(needed for WTT) - see table below 


Manually flash the new test image on at least one of the devices using 
FFUTool with the -flash switch (NOT -force) to ensure it is a valid image 
Manually run the basic BVT job against the new build on at least one of the 
devices to ensure it is a lab-ready image 

Manually run the System Shutdown and Reboot API test job on at least one 
of the devices to ensure it is a lab-ready image 


Device Dimensions Onboarding Checklist 
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; Confirm that both "disable charging" text files are present in the proper 
: DPP folder 
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———— SSS 
Fear 

ee 

Codename 

Pe 

lcs AN i ci 

ee 


Internal Storage Size aa 4000 (4Gb) or 8000 (8GB) or 16000 (16gb) etc. 
in MB 


Internal Storage type ol eMMC 


System RAM 2Gb, 1GB, 512mb 


Cellular Radio GSM or CDMA or TDSCDMA 
Protocol 


Anything else we should know about the device prior to 
Notes testing e.g. reference device, board only 


Please send to Microsoft OFLabs team 


Optional components that might not be implemented 
Gyro Supported? Yes/No are in this section (add additional lines if necessary) 
Front Facing Camera | Yes/No 
ALS Yes/No 
Magnometer Yes/No 
NFC Yes/No 
Proximity Yes/No 
Accelerometer Yes/No 
Flash Yes/No 
Other Sensors Yes/No 


6. Appendix 


Battery Blank Information Guide 
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The purpose of this guide is to explain the purpose and technical description for the 
“Battery Blank”. This information guide does not dictate design requirements and should 
not be used to establish such requirements. Because batteries differ greatly in form, design 
and function, it would be impractical for Microsoft to provide design requirements. Instead, 
this information guide should be used to assist in the process of determining how best to 
construct a battery blank. 


1. Why do! need a Battery Blank? Can’t | just power my mobile device 
directly with an external power source? 


a. 


A battery blank goes a step further than just direct power to a device by 
spoofing the elements of an actual battery which are often required by the 
device to power-on. This enables the device to be used for long-term testing 
in lab environments that may not normally be possible due to limited battery 
capacity. This is accomplished by allowing the mobile device to communicate 
normally with the battery even though current is being supplied by an 
external power source. In some very limited cases, you can get away with 
directly powering a mobile device from an external power source such as a 
4.2vdc power supply. In most cases, however, the device may fail to operate 
correctly when it can’t communicate with its own battery. The problems you 
may encounter include: Failure to power-on, failure to boot completely, 
premature or false low battery alarm, instant shut-down upon boot or many 
other types of behavior. 


2. How does a mobile device “communicate” with its own battery? What is a 
“smart battery”? 


a. 


Most modern mobile devices communicate with the battery using a one-wire 
serial interface known as “HDQ” (see FAQ #5 for a description of the term 
“HDQ”). The on-board battery circuit monitors a voltage drop across a small 
current sense resistor connected in series with the battery output to 
determine charge and discharge activity of the battery. Compensations for 
battery age, temperature, self-discharge, and discharge rate are applied to 
the capacity measurements to provide available time-to-empty information 
across a wide range of operating conditions. Available battery capacity is 
automatically recalibrated, or learned, in the course of a discharge cycle from 
full to empty. These circuits communicate to the mobile device over an 
“HDQ” one-wire or I?C serial interface. 


3. Does a Battery Blank need to function EXACTLY like a battery? What are 
the actual requirements? 


a. 


The Battery Blank is used only as a means to provide continuous external 
power to the device to enable long-term testing that would otherwise be 
impossible using the battery alone. It is not used as an instrument to test the 
operation or design of the actually battery. For the sake of simplicity, the 
battery blank should provide only what is normally required to power the 
phone in the same manner that the battery would. For example, if the device 
design requires communication with a battery-based HDQ or IC circuit, then 
the battery blank should provide that capability. If the battery uses a known 
or expected resistance for ID, authentication or a thermistor (TH) circuit, the 
blank should provide that as well. Exactly how the required characteristics to 
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mimic the battery are provided by the battery blank to the device are entirely 
up to the OEM. 


4. My battery uses an HDQ or I?C-based Fuel Gauge Circuit and my device 
requires this circuit to be present to boot-up. What is required to spoof 
this circuit so the battery blank can be used instead of the battery? 


a. 


This is unknown to Microsoft since we didn’t design the circuit. We expect the 
OEM hardware designers to understand these requirements since they have 
access to the schematics, design references and hardware specifications that 
would stipulate these requirements. We rely on these same designers to 
fabricate the battery blank and ensure it meets both the Chassis 
specifications and hardware requirements. 


5. What does the acronym “HDQ” mean when used in reference to batteries 
and fuel gauge circuits? 


a. 


“HDQ” is a composite acronym used to describe the one-wire serial 
communications circuit between the battery and the mobile device. “H” in 
the acronym means High-speed, and “DQ” is a standardized electronics term 
that describes Data Input (D) and Data Output (Q) used with many different 
types of “Flip-Flop” circuits. Put together, you get “High-speed Data Input / 
Data Output’, or just “HDQ” for short. 


6. How difficult is it to make each type of Battery Blank? Are there any 
construction guidelines? 


a. 


This depends on the complexity of the battery circuit used, and only the OEM 
or its assigned engineers have a complete understanding of the requirements 
necessary to mimic the original battery. As for the physical construction, 
there are many possible designs, most of which probably started out as an 
original battery that had the chemical cell removed leaving only the shell and 
the battery circuit board behind. In some designs where the battery doesn’t 
provide I?C or HDQ 1-wire communications, construction may be as simple as 
routing external wires to the appropriate pads on the phone-side of the 
battery circuit board. In other cases, you may have to adjust the way your 
safety circuit operates or even remove it from the circuit. In still other cases, 
you may have to alter the software on the phone to accommodate the change 
to the battery. It really just depends on what the device expects to see from 
the battery to assume a genuine battery is being used instead of the battery 
blank. More on this specific point will be covered later in this document. 

In most cases, removing the battery cell leaves behind a very flimsy and 
fragile battery frame. Once the wires are attached to the battery board and 
the required changes to the battery board electronics have been made (if 
any), we recommend that the blank we “potted” or filled with a stiff material 
that restores the rigidity to the plastic frame and makes the battery blank 
durable. Ideally, the wires would be potted as well, providing strain relief. 
Providing a battery blank without any strain relief on the wires is strongly 
discouraged. Batteries that have sheet metal cases are usually rigid enough 
but may cause other problems with the wires by exposing sharp edges that 
would cut into the wire insulation. Hot glue is a good option for holding wires 
and other required parts inside the frame (such as any needed capacitors). 
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Keep in mind when designing your battery blank that it should be durable and 
able to handle multiple insertion and removal cycles without any damage to 
the blank. The blank should fit snug into the battery compartment, just like 
the original battery. It should never be so loose that it would fall out by itself, 
but it also shouldn’t be too tight. The wires coming out of the battery blank 
should deflect out and away from the device. There should be no 
supplemental components protruding from the back of the battery blank that 
increase its thickness (like large electrolytic capacitors or other electronic 
components). If capacitors or other large components are required, please 
consider using surface-mount devices to keep the size down as much as 
possible. These specific points are covered in more detail later in this 
document. 
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Sample Battery Protection and Communication Circuits 


Sizs-ve  PUCANO2S-2-A Sp s> MMT 


2? 


4 o | (MIRA P } 
wipranc  @ 


| @VESSET VER.D-21 
Rap ™ 330400, 9,” 


These battery circuits were removed from 11 different types of batteries. The cells to which 
they were once permanently attached have been removed and recycled and are not shown 
in this exhibit. The circuits showing the metal silver tabs on the left and right edges of the 
circuit board are where the battery cell connected. The other circuits showing 4 gold 
contacts are where the device would connect. The pin arrangement can vary greatly from 
battery-to-battery, but most include a minimum of 3 contacts to a maximum of 6 contacts. 
The pins usually provide +, -, HDQ, ID or TH, although this varies greatly from OEM to OEM. 
Some have fuel gauge chips and some don’t. There is no magic done inside the actual 
battery cell that provides any kind of physical battery characteristics. This information is all 
fabricated, calculated, measured or guesstimated by the on-board electronics that are 
factory programmed (if needed) and permanently attached to factory-fresh batteries. These 
circuits are designed to see some amount of battery cell voltage 100% of the time for the 
entire life of the battery cell, even when the battery is technically “discharged”. Once 
removed from the battery, all of the information that has been recorded over the life of the 
attached battery cell can become invalidated or lost by the electronics. 


As you can see, there are a wide variety of styles, shapes and circuitry available just inside 
the battery alone. As such, it would be impractical for Microsoft to dictate the specifics 

behind what exactly is needed by your device to make the battery blank function correctly, 
especially in cases where original battery electronics are recycled for use in battery blanks. 
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In many cases, these circuits also act to “authenticate” the attached device by 
communicating with it over the HDQ or I?C interface upon insertion into the device: If the 
device properly authenticates with the battery, the battery “turns-on” enabling full output 
power to the device, thus allowing it to power-up. Additionally, the fuel gauge circuit (if 
present) communicates with the mobile device over the HDQ (or I?C) one-wire serial 
interface to relay operational battery characteristics to the mobile device. Using this 
information, the battery electronics can provide a number of usage characteristics, including 
approximate battery life remaining, current power consumption, current voltage level, time- 
to-empty, number of charge cycles, etc. For mobile device batteries, a more common 
“authentication” method is to simply provide a fixed resistance from ground through an “ID” 
pin that is used by the phone to ensure a genuine battery is attached (as long as the 
resistance matches). This particular tactic goes both ways, as well - the battery can actually 
require a fixed resistance jn the mobile device before turning on its primary output. Your 
battery blank should supply any of the needed parameters required to accurately simulate a 
real battery while allowing the device to be powered from an external power source. 


WARNING: It is very important to remember that the circuits shown above were specifically 
designed to protect a physical battery cell. Once removed, the operational parameters of 
that battery cell may be lost or invalidated by the same circuit that communicates with the 
phone, and the operational information passed back to the phone may reflect that change 
and cause the device to behave differently. Likewise, the safety circuits normally expecting 
to see a constant voltage provided by the battery cell would now see voltage being switched 
on and off through the battery blank, and this could cause the safety circuits to fail or 
permanently trip which could in turn erroneously open the output of the battery blank during 
testing (we’ve seen this before). It may be prudent for you to consider bypassing any safety 
circuitry normally designed to protect a battery cell as these circuits will likely “detect” the 
on-and-off power cycles through the battery blank as problems with the “battery”. These 
unanticipated failures of the safety circuitry may not necessarily manifest themselves right 
away, either. The battery blank may appear to function normally from anywhere to 10 to 
hundreds of power cycles before they trip. 


Designing a Battery Blank - An example 

A large number of single-chip solutions that combine specially-designed battery protection 
electronics with the ability to trigger external FETs are currently available and are becoming 
more pervasive in the marketplace. The use of these electronics in battery blanks can 
occasionally cause more harm than good since they are being used outside of their designed 
intent and specifications and can therefore erroneously (and often unexpectedly) cause the 
output to open. 


Since the OEM has the required confidential information (i.e., schematics and design 
specifications) needed to determine how best to bypass these safety circuits, we rely on 
them to provide any needed modifications to the battery blanks. 


The following information is provided as a generalized example of how to construct a battery 
blank. It shows the evolution from what at first appears to be a good solution to what 
ultimately had to be changed to make the battery blank robust and reliable for use in the 
lab. 
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In the above picture, the OEM has elected to use the Dallas/Maxim DS2784, a popular single- 
cell, stand-alone fuel gauge IC. The fuel gauge provides accurate estimates of remaining 
capacity and reports timely voltage, temperature, and current-measurement data. Capacity 
estimates are calculated from a piecewise-linear model of the battery performance over load 
and temperature, and system parameters for full and empty conditions. The algorithm 
parameters are user programmable and can be modified in pack. Critical capacity and 
aging data are periodically saved to EEPROM in case of loss of power due to a 
short circuit or deep depletion. 


That last bolded text is very important, since it indicates that this part is specifically 
designed to handle scenarios where the battery enters deep depletion, a characteristic 
somewhat matched by switching the power off to a battery blank. While comforting at first 
glance, the real-world application is far less obvious. The Typical Operating Circuit provided 
by the DS2784 Datasheet shows that the chip controls a dual-FET arrangement placed in 
series with POSITIVE lead to the device designed to interrupt the output as deemed 
appropriate by the DS2784: 
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DS2784 TYPICAL OPERATING CIRCUIT SCHEMATIC 


The quick and easy way to make a Battery Blank in this case might first appear to be as 
simple as replacing the physical battery cell with the required Molex connector: 


Connector Pins~ Taw 
Molex PN 39-00-0047. ~~ 
Digikey PN WM2503-ND ~~~ 


Connector Shell>"~ 
Molex PN 39-01-2020 
Digikey PN WM3700-ND 


By simply replacing the battery cell with the Molex connector, you leave the FETs in series 
with the POSITIVE. The safety circuit is still intact and fully operational. Any error condition 
detected by the DS2784 could cause the FETs to trigger OPEN, even under normal 
operational test conditions. The DS2784 assumes a battery cel// is connected, not an 
external power source, and proper operation of the DS2784 per its original design 
specification is no longer guaranteed. There are countless conditions that could cause a 
malfunction in this unnatural application of the DS2784, but ultimately the end result is that 
the Battery Blank stops working and power stops flowing to the mobile device. 
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There are a number of workarounds possible, but ultimately the designers of the battery and 
battery interface need to determine the best solution. In this particular example, the device 
explicitly requires the HDQ circuit to be connected to the phone. That means that simply 
bypassing the DS2784 entirely wouldn't work as it needs power itself to provide the required 
communications to the mobile device. That leaves several possible options: 


1. Disable the need for HDQ in the device through a software change and hardwire a 
bypass around the FET. 

a. This option requires a software workaround coupled with a hardware change 
and is not ideal, especially if part of the device testing covers communications 
with the battery. 

b. This is probably the /east ideal option as it could lead to the discovery of non- 
real-world bugs and might also precipitate additional software problems in the 
device relating to charging or power management. 

2. Design your device to use HDQ if present but build-in an option to bypass this 
requirement if another operational parameter is met such as a fixed resistance to 
ground in place of HDQ. 

a. This solution is very ideal but requires additional development and 
implementation during the hardware development cycle which may be too 
late at this point or simply not an option to begin with. 

b. The idea here is that if a battery blank doesn’t provide HDQ signaling because 
it has been removed from the blank that something else has been added 
(such as a fixed resistance) to trigger an “HDQ requirement over-ride” in the 
device allowing the device to operate normally as though the HDQ signal was 
present. 

3. Bypass only the FET so even if it does attempt to open, power will still flow to the P+ 
contact. 

a. This option doesn’t cover the changes or error conditions that the DS2784 
might be reporting to the phone over the HDQ line which could still negatively 
impact operation of the device. 

b. Unless the DS2784 is sending information over HDQ to the phone that impacts 
its operation, this is probably the best and easiest solution to implement. 


Assuming Option #3 is ideal in this particular example, we only need to find a way to bypass 
the FET while leaving the DS2784 intact to do its thing. On some battery board designs 
where schematics and layout diagrams are not available, you may have to use a multi-meter 
to identify the direct wire to the P+ pad on the device-side of the battery board. In other 
cases, silk-screening may point you directly to the answer: 
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A P+ Test Pad is conveniently located on the component-side of the battery board. All that 
is required now is to bridge positive voltage being provided to B+ to this P+ Test Pad as 
well. This will provide voltage to the DS2784 allowing it to operate normally while also 
bypassing the FET if it should attempt to open. 


The end result after modifying the battery board with a short around the FET: 


-— 


Connector Shel Sd 
Molex PN 39-01-2020 
Digikey PN WM3700-ND 


Keep in mind that this was only an example using a popular Battery Management part. 
Every design is different, and the solution described above is only one possible example 
designed to make you think about the potential problems you may encounter in designing or 
building a battery blank. This represents one of the more complex examples seen in the 
field. For batteries that provide only a single-chip safety circuit that controls a FET, the 
solution is usually very simple: Just bypass the FET. No need to worry about sour grapes 
from the HDQ line because it doesn’t exist. It is also important to note that the majority of 
safety interrupt circuits observed in the field actually interrupt the NEGATIVE lead, not the 
positive lead as used by the DS2784. The same bypass principles apply, however. 
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Building for Durability - Recommendation, “Do’s” and 


“Don’ ts” 


As previously mentioned, once you peel away the labels and very carefully remove the 
chemical battery cell from a production battery, you’re usually left with a flimsy, thin, open 
plastic frame. Not a picture of durability by any means, so in this section, we'll cover some 
recommendations that might guide you down a more rigid and durable path. 


It is important to remember that you’re building a battery blank for use in a lab 
environment. As such, it needs to be durable and able to resist excessive and often 
unreasonable working conditions. Although personnel are trained not to use the wires as a 
means to remove the battery blank, some people do so without thinking about it. 


POTTING 

Although not listed as a specific requirement in the Chassis specification, your battery blank 
should closely approximate the designed durability of the production battery. There area 
number of ways to do that. Most include potting (or filling) the entire empty cavity with 
epoxy, hot glue, silicon adhesive, rubber sheet or a plastic filler of some type. Whatever 
option you ultimately choose, try to build your blank in such a way that access to the actual 
battery board itself isn’t permanently blocked. The reason for this request is that if you did 
have a problem with the design of your blank and it failed for some reason, it is nearly 
impossible to clear epoxy off the battery board without damaging the circuitry which would 
seriously inhibit any troubleshooting efforts. In this case, the OEM would be requested to 
provide fresh, working blanks to replace the ones that couldn’t be repaired. Suggestions for 
this include adding a layer of Kapton tape between the battery board and the potting 
compound, or using a potting compound such as hot glue that can be cooled and fractured 
away from the battery board without damage to the components. 


Some examples of Potting materials and compounds: 


e §=6Air (i.e., no potting) 
o Advantages 
=» None 
o Disadvantages 
= No strain relief for the wires connected to the battery board 
= Nothing to fill the flimsy plastic frame 
=" Nothing to secure the battery board in place 
= Nothing to protect the interior electronics 
e Hot Glue 
o Advantages 
«Many different kinds available to cover most scenarios 
«= Hot glue sticks are cheap 
«Easy to apply - heat and squirt, no mixing required 
«Usually easy to clean off unwanted residues 
* Doesn't chemically bond with anything else 
o Disadvantages 
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e Epoxy 


Can make a terrific mess if not carefully contained 

Can easily and quickly burn the assembler 

Can take anywhere from 2 minutes to 2 hours to solidify 

Heat from the glue could soften and distort the thin, plastic frame 


o Advantages 


Very dense material; extremely rigid when properly mixed and cured 
Can be drilled or easily shaped as needed once cured 

Comes in hand-mixable putties that work very well for this application 
and avoid some of the pitfalls associated with liquid-based, two-part 
epoxy mixes 


o Disadvantages 


Can chemically bond to certain other materials making removal 
extremely difficult 

Exothermic reaction when curing can release considerable heat that 
could soften and distort the thin, plastic frame 

Two-part liquids usually fill every void possible as it thins considerably 
just before hardening 

Take anywhere from 1 minute to 1 day to cure depending on the 
formula 

Very tedious to remove if needed. Will usually damage the enclosure 
during the removal 


e Other Solid Filler Materials: Rubber, Plastic, Wood, Solid Cardboard 
o Advantages 


Easily removable if needed 
Generally holds shape well if cut precisely to fit case 


o Disadvantages 


Can be tedious to cut depending on material 

Can be hard to anchor wires to for strain relief purposes 

Doesn't usually stick to the plastic frame and may require a tape wrap 
or other adhesive to hold the material in place inside the frame 


Good and Bad Implementations 


Some Battery Blanks require supplemental components such as capacitors to be placed 
within the battery frame. If needed (as determined by the OEM), these parts should fit 
entirely inside the battery cavity of the battery frame. Any protrusions other than the wires 
leading to the Molex connector could negatively impact overall device thickness and may 
hinder our ability to place the device into one of our automated testing instruments. 


Here is an example of a poorly designed Battery Blank: 
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The 2200uF capacitor shown above increased the thickness of the device by more than 
13mm. In this case, laying the electrolytic capacitor on its side or using surface-mount 
tantalum capacitors instead of the style shown would have significantly reduced or even 
completely eliminated the extra thickness. Also note the lack of any reasonable strain relief 
on the wires. Even a small tug on a wire could pull it out of the hot glue or loosen it. We 
also discovered that the wiring hidden inside the sea of hot glue wasn’t soldered together, it 
was only twisted creating a very unreliable electrical connection (see detail picture above 
right). 


Here are examples of well-designed Battery Blank: 


On the right below note the secure connections to the cable and materials used ensuring a 
good fit to the device. 


On the left above, Note the uniform thickness throughout the battery. Sheet metal holds the 
frame together on top and bottom and keeps the entire assembly rigid. The area where the 
wires protrude is sealed with hot glue to provide solid strain relief and to keep the wires 
from being cut by the edge of the sheet metal. Electronically, the safety FET has been 
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removed and replaced with solid wire. This is a solid, well-thought-out Battery Blank 
implementation that very closely mimics the original OEM battery. 


Safety Considerations, General Guidelines and Warnings 


There are 2 ways to create Battery Blanks: 


1. From Scratch: Microsoft strongly recommends that an OEM create their Battery 
Blanks from scratch to avoid the potential dangers and pitfalls associated with 
transforming actual device batteries into Battery Blanks. Doing so has been proven 
to generate safe, reliable Battery Blanks that are as durable and reliable as a 
production battery. 

2. Modifying Existing Batteries: Microsoft strongly recommends building the Battery 
Blank from scratch, however if the OEM does choose to transform existing batteries 
into battery blanks, please read the following section in its entirety. 


NOTE: The information provided below is not inclusive of all of the potential dangers 
associated the disassembly of a sealed battery unit. Each battery design is different and will 
likely require a different disassembly method. 


The general process is disassembly begins with careful removal of the labels on the battery. 
When removing the label(s), take care not to puncture or scratch the side of the battery cell 
with your tools. 


Once the labels are removed, the cell is generally spot-welded to an in-line Polyfuse and 
then soldered (or spot welded) to the actual battery circuit board. When disconnecting the 
battery cell from the battery board, cut only 1 wire at a time and take extra measures to 
keep the wires from shorting together. Any short at this point could permanently damage 
the Battery Protection Circuitry that your device may require to function normally - you 
could easily “Brick your Battery Blank”. 


Once the cells are removed from the battery frame, properly dispose of the cells. LiPol and 
Li-ION cells do NOT go in the regular trash and must be properly recycled. Most Office 
Supply Stores have battery recycling centers. 


e If at any time you witness a battery starting to balloon or swell up, 
discontinue the disassembly process immediately and verify that there are no 
shorts on the battery. Deal with this problem completely before continuing. 
Observe it in a safe place away from any combustible materials for at least 
20 minutes. 

¢ When removing the wires (flat or round) from the battery cell, NEVER peel the 
spot-welded wires off the actual battery cell. Doing so may breach the wall of 
the cell causing the materials inside the cell to ignite. 

e Any battery cell that has been shorted or punctured may leak and 
spontaneously ignite. In the event of a puncture or breach, remove the 
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battery for observation and place in a safe, open area away from any 
combustible material for approximately 20 minutes. 

e Batteries should remain at room temperature during the entire disassembly 
procedure. Cells that get warm or hot during removal usually indicate a short 
circuit which could ultimately cause an explosion and possible spontaneous 
ignition of the battery chemicals. Always keep track of the exposed 
battery cells. 

e Never store battery cells in areas with extreme temperatures and make sure 
they don’t short-out to each other in the storage container. 

e Properly dispose of battery cells as soon as possible - do not collect them for 
several weeks. 

e Insulate the Positive plate of a battery cell with a durable material such as 
Kapton tape to prevent the cell from shorting out. 

e Never, under any circumstance, attempt to disassemble a sealed 
battery cell. It will ignite and start an uncontrollable, chemical fire 
as the Lithium metal reacts with oxygen and moisture in the air. 
Water will not extinguish a chemical fire of this type and will only 
cause a much more violent reaction. Have appropriate fire control 
equipment on hand and ready to use. Remember that metal fires 
(lithium batteries) require uncommon Class D fire extinguishers 
which are specifically designed to smother burning metal fires. 


- End of document - 
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